Adapative and dynamic data synchronization system for managing data and inventory

ABSTRACT

A system and method for adaptive and dynamic synchronization includes a data synchronization controller which enables synchronization of a plurality of different data types between a main computer and one or more remotely disposed computer elements. The controller includes an orchestrator which responds to requests for data synchronization for components in accordance with predetermined policies maintained by a policy management system. A synchronization interface is controlled by the orchestrator in accordance with the policies to select a synchronization engine to service requests for synchronization of different data types from the orchestrator. Synchronization may be handled for on demand and/or for on schedule requests for synchronization in the policy-based system and method.

RELATED APPLICATION INFORMATION

This application is a Divisional application of co-pending U.S. patentapplication Ser. No. 11/127,980 filed on May 12, 2005, incorporatedherein by reference in its entirety.

BACKGROUND

1. Technical Field

The present invention relates to a framework for managing data andsynchronization of stored data or inventory, and in particular to asystem and method for addressing inquiry or order failures usingavailable resources in a policy-based environment.

2. Description of the Related Art

Retail enterprises may include hundreds or even thousands of small andmedium retail stores that provide sales, inventory and other services tocustomers. The retail stores have many computational and display nodesto enables shopping for products or services, looking up prices,inventory accepting orders, etc. The retail stores obtain information oncustomers, inventory levels of products and latest product prices fromthe enterprise, and these are done based on policies such as on-demand,periodic or enterprise-driven ways of invoking the sharing ofinformation. Information created at the retail stores (e.g., orders bycustomers) gets periodically updated by the store to the Enterprisesystems.

A retail store may need important information from and Enterprisesystem, but for a number of reasons may be unable to contact theEnterprise system servers electronically. Such information may includethe latest pricing, inventory or other information needed to make asale. In the current environment, most retail stores have to wait untilthe communication is reestablished or repaired to the Enterprise system.This could result in the loss of sales, taking orders where products orservices are not available due to lack of inventory or staff, andultimately in customer dissatisfaction.

SUMMARY

A system and method for sharing information includes after trying toconnect to a main computer from a local node in a system, failing toreceive up-to-date information from the main computer. The up-to-dateinformation is requested from one or more alternate nodes which haveaccess to the main computer or have accessed the main computer morerecently than from the local node. A reply and the up-to-dateinformation are received from one of the alternate nodes wherein theup-to-date information is more current than the information at the localnode.

A system includes a data synchronization controller which enablessynchronization of data between a main computer and one or more remotelydisposed computer elements. The controller includes an orchestratorwhich responds to requests for data synchronization for a plurality ofcomponents in accordance with predetermined policies maintained by apolicy management system. A synchronization interface is controlled bythe orchestrator in accordance with the policies to select asynchronization engine to service requests for synchronization from theorchestrator.

Data synchronization is performed dynamically on demand and/or onschedule. Synchronization is driven and/or controlled by policies, whichexternalizes the dynamic aspect of the data synchronization, andprovides the ability to synch any data type (using different synchengines dictated by the policies).

These and other objects, features and advantages will become apparentfrom the following detailed description of illustrative embodimentsthereof, which is to be read in connection with the accompanyingdrawings.

BRIEF DESCRIPTION OF DRAWINGS

The disclosure will provide details in the following description ofpreferred embodiments with reference to the following figures wherein:

FIG. 1 is a block/flow diagram showing a system having a data synccontroller for handling synch requests in a system;

FIG. 2 is a routing protocol stack illustratively showing informationcontent and routing used in requests;

FIG. 3 is a routing flowchart illustratively showing request routing;

FIG. 4 is a flowchart illustratively showing how a request is handled;

FIG. 5 is a state machine diagram illustratively showing an on-schedulesynch request life cycle;

FIG. 6 is a state machine diagram illustratively showing an on-demandsynch request life cycle;

FIG. 7 is a diagram illustratively showing state machine engineinteraction with components of a controller;

FIG. 8 is a block/flow diagram showing a particularly usefulimplementation of the controller in a distributed system;

FIG. 9 is a diagram showing class interactions for components of thecontroller in handling component requests;

FIG. 10 is a diagram showing class interactions for when synchronizationbegins and ends; and

FIG. 11 is a block diagram showing an illustrative method for one usefulembodiment of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Embodiments of the present invention provide an adaptive and dynamic wayfor enabling retail stores to get enterprise information by monitoring,detecting and adapting to communication failures by looking for otherpotential trusted peers with inventory, price information or otherinformation needed.

In particularly useful embodiments, retail stores of other peer sourcesdynamically synchronize information based on policies established by amain policy making source, such as an Enterprise server. Retail storesservers which maintain retail prices, inventory and order informationcan adapt to failures by contacting peer retail stores in a local regionor within a broader region in a dynamic fashion by maintaining statuswith the retail servers with a network or region.

The retail servers detect the failures automatically by monitoring thesystem components such as network connectivity, retail serverperformance and application. A dynamic routing mechanism may be providedon the retail store server configuration and maps of the retail storeswithin a region or worldwide. Reliability is provided to the retailstores by enabling access to the Enterprise through another retail storeor stores and receives the appropriate information for prices,availability, etc. in time to make a sale.

It should be understood that the elements shown in the FIGS. may beimplemented in various forms of hardware, software or combinationsthereof. Preferably, these elements are implemented in a combination ofhardware and software on one or more appropriately programmedgeneral-purpose digital computers having a processor and memory andinput/output interfaces.

Embodiments of the present invention can take the form of an entirelyhardware embodiment, an entirely software embodiment or an embodimentincluding both hardware and software elements. In a preferredembodiment, the present invention is implemented in software, whichincludes but is not limited to firmware, resident software, microcode,etc.

Furthermore, the invention can take the form of a computer programproduct accessible from a computer-usable or computer-readable mediumproviding program code for use by or in connection with a computer orany instruction execution system. For the purposes of this description,a computer-usable or computer readable medium can be any apparatus thatmay include, store, communicate, propagate, or transport the program foruse by or in connection with the instruction execution system,apparatus, or device. The medium can be an electronic, magnetic,optical, electromagnetic, infrared, or semiconductor system (orapparatus or device) or a propagation medium. Examples of acomputer-readable medium include a semiconductor or solid state memory,magnetic tape, a removable computer diskette, a random access memory(RAM), a read-only memory (ROM), a rigid magnetic disk and an opticaldisk. Current examples of optical disks include compact disk-read onlymemory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing programcode may include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code to reduce the number of times code is retrieved frombulk storage during execution. Input/output or I/O devices (includingbut not limited to keyboards, displays, pointing devices, etc.) may becoupled to the system either directly or through intervening I/Ocontrollers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modem and Ethernet cards are just a few of thecurrently available types of network adapters.

Data synchronization components for a network based commerce system willbe described in terms of an enterprise system or a central server ordatabase. The enterprise may include one or more servers and provideinformation updates and maintain up-to-date records of information.While the system will be described in terms of a business enterprisewith distributed locations, the present invention is much broader andmay be employed in a distributed network framework where contemporaneousinformation sharing is needed.

The functionalities of a synchronization aspect of the system mayinclude the following features: 1) capability to synchronize databetween system nodes, for example, from commerce components such ascatalogs, prices, offers, orders, promotion, membership profileinformation, etc.; 2) capability to synchronize data based on at leastthe following request types: “on-demand”, “timer-based” and“multi-channel access”; 3) provide sync-orchestration to handlesynchronization processes between commerce functions on the store serverand the enterprise server; 4) capabilities for a synchronization engineto handle “what” and “when” type inquiries to synchronize based onpolicies; 5) capabilities to handle failures of all kinds, e.g.,disconnection, memory loss, low disk-space, special exceptions andothers.

One of the capabilities of the data synchronization component is tocreate an autonomic system to self-manage and self-recover from failureand other system events. A formal and consistent way of capturing thedynamic aspect of request information, and knowledge to respond tovarious aspects of behavior of the system and synchronization process isprovided. The knowledge is needed to be able to self-manage the systemin situations that could change dynamically. The entities of response tothe various aspects of situations should be externalized from theapplication code where changes can be easily made without changing theapplication codes.

One approach taken to accomplish this is to make an embodiment of thedata synchronization system, a policy and state machine based system.Policy is used to capture the dynamic aspect of the data, and the statemachine mechanism is used to capture the dynamic aspect of the response(to the data). For example, data components can be synchronized using aplurality of different synch engines depending on data-type. Theseengines may be selected by a policy set up by an authority, such as anenterprise server. Should it be desired to change these assignments, theauthority would only have to reissue the policy, thereby settingchanging the synch engine or other components employed for specifictasks, such as synchronization of data, etc.

Referring now to the drawings in which like numerals represent the sameor similar elements and initially to FIG. 1, a high-level logical viewof a data synchronization system 100 with core logical components andthe interaction among the components is illustratively shown. Acontroller 102 includes modules and systems for managing datasynchronization between a main system and remote system. Controller 102may include a sync orchestrator 104, which provides interfaces forcommunication, status and response for the other application components.

Controller 102 may include many functions and features to provideacceptable synch results. A timer service 106 may be provided. Timer 106may perform known methods to permit timing among components, such asapplying timestamps to objects, etc. In addition, a policy managementsystem 112 may employ an existing package service, which may becommercially available.

Synch orchestrator or orchestrator 104 functions as the managing unit ofthe data synchronization component or controller 102. Orchestrator 104provides services (with a list of interfaces) to enable components torequest synchronization, and creates state machine instances to carry onthe sync request. The orchestrator 104 also maintains all registeredlisteners for notification of sync status, and also carries out thenotification and sync-status information.

The orchestrator 104 handle sync requests from one or more systemcomponents (e.g., on-demand sync). The request may include the XMLdocument (that includes policies which may be maintained in a policymanagement system 112 and managed by a policy manager 110) of thesynchronization process. The orchestrator 104 creates a sync requeststate machine using a state machine engine 114 to process and persistthe synchronization request and manage the status of the request whilein operation. The orchestrator 104 invokes the policy manager 110 toobtain policies 112 for a synchronization, and set up a scheduler 107(if needed) for generating the synchronization events.

In one example, the orchestrator 104 may invoke a pre-specifieddata-sync engine (e.g., file synch engine 120, JDBC (JAVA™ DatabaseConnectivity) synch engine 122 and/or XYZ sync engine 124) to begin thesync process. The sync-engines 120, 122, 124 interface with thecomponent data for synchronization to be performed. The orchestrator 104responds to the component once the synchronization finishes, and updatesthe request status. The orchestrator 104 chooses the synch engine basedon policies from the policy manager 110.

The scheduler 107 maintains pending sync requests to wait for their turnto be synchronized. The two main tasks of the scheduler 107 includeinitiating the sync when the scheduled time is up and maintaining queueof scheduled sync requests. The queue includes due sync requests. Tokeep the integrity of the data, the order of the sync requests receivedis maintained, the syncs that are due have to be suspended to wait fortheir turn to sync.

The state machine engine 114 maintains all the sync request statemachine instances. It accepts events and dispatches the events to theappropriate state machine instances and performs the correspondingactions. Engine 114 may be employed to react to system failures, such asfailures in communication with an enterprise server or the like.

An optimizer 126 may be employed to attempt to optimize the sync bymaking sure that the minimum amount of syncing is performed and yetsatisfy the client request to get the most updated sync request. If thesync condition, which is expressed through policy, includes a delta(difference) guarantee of freshness, then a scheduled or queue sync willbe abandoned if the previous sync request (of the same data) is stillwithin the freshness threshold.

The policy manager 110 is the mediator between the data sync controller102 components and the policy-management system 112. Policy manager 110knows the raw format of a policy that is used by the policy-managementsystem 112 and translates it to, e.g., a java object that is understoodby the other components. When other components make a request forinformation, the policy manager 110 will solicit guidance/decisions fromthe policy-management system 112 and then present the result in, say,java objects type understood by the data sync controller 102 components.The policy-management system 112 is expected to notify the policymanager 110 of any updates of the policies, then the policy manager 110will notify data sync controller 102 of such change so that appropriatesteps can be taken.

A sync engine plug-in 128 performs the actual synchronization with theserver or servers. This interface may include a generic interface thatcan be performed by any synchronization engine of a specific data typeand be plug-and-play into the present framework.

The orchestrator 104 and sync engine (SyncPlugIn 128 implementation) maybe packaged as a web application and installed as resources, e.g., “SyncEngine Orchestrator Provider” and “General Sync Engine Provider”. JNDI(JAVA™ Naming and Directory Interface) names may be associated with eachone of the resource names and a component that needs these services willdo a JNDI lookup to get the services, similar, e.g., to a JDBC Providerresource.

On-schedule sync requests and any situation (events) and responses willpreferably be stored in policy files. The policy file will be loaded tothe policy-management system 112 at the system startup time. Policiesare not expected to change too much over time. However, if they dochange, the policy-management system 112 will handle and notify the datasync orchestrator 104 of the appropriate updates. To check or requestthe status for synchronization, a call-back mechanism 195 is providedwhere the listeners register with data sync 102 and pass a call-backinterface 195. The data sync 102 will notify the listeners through theprovided call-back interface when the sync has been completed (e.g.,response 193).

The following is an exemplary sequence of component interactions usingcontroller 102:

Get the orchestrator resource by doing a JNDI name lookup:

-   -   SyncOperation syncCtrl=(SyncOperation) new InitialContext(        ).lookup(SyncOrchestrator.Name);    -   Register with the orchestrator: SyncCtrl.register(id)

If there are any scheduled policies in a policy file, load the policies:

SyncCtrl.loadPolicies(InputStream);

Perform any operations/queries defined in syncCtrl (SyncOperation).

The data sync engine interface 128 needs to be able to sync any type ofdata format. An abstraction layer or interface of a sync engine needs tobe defined so that different kinds of sync engines (e.g., 120, 122, 124,etc.) that know how to handle the synchronization of different datatypes can be replaced or instantiated easily. For an example, to sync anExcel® spreadsheet, a different sync engine may be needed which may bedifferent from the sync engine used to sync any JDBC-compliant data basedata.

The orchestrator 104 communicates with a sync engine (e.g., 120) via thesync engine adapter created that is compliant with a plurality ofinterfaces. Advantageously, the sync engine selected is preferablyselected based on current policies 112 as provided by policy manager110. In this way, any data type can easily be synchronized using thepresent system. The policy management system 112 may be used to definethe policy grammar, evaluate and manage the policies.

Table 1 lists possible sync statuses returned from the sync engine tothe components registered to receive the status of a sync request.

TABLE 1 Exception code Description Sync_Success Synchronization success.Sync_Err_Failed Synchronization failed. Sync_Err_AuthFailedAuthorization failed. Sync_Err_Conflict A conflict occurred duringsynchronization. Sync_Err_ConnFailed Failed to connect to the targetdata source. Sync_Err_NoData The requested data is not found.Sync_Err_OpFailed An illegal operation occurred. Sync_Err_OutOfMemoryFailed to allocate memory. Sync_Err_ReadOnly An attempt to updateread-only data occurred. Sync_Err_Timeout A timeout occurred.Sync_Err_ServerException The server reported unknown exceptions.Sync_Err_ServerBusy The sync server is busy or is not responding.Sync_Err_CancelSync Canceling synchronization. Sync_Err_HostUnknownUnable to resolve host name

Timer service 106 provides an alarm or wake-up service. It accepts aschedule time from a caller and notifies the caller when the time is up.The scheduler 107 uses this service for on-schedule sync. A JMX (JAVA™Management Extensions) timer may be employed to provide this service.JMX timer service uses a JMX notification framework which is based onthe JAVA™ event mechanism to notify the caller.

A router 130 provides an adaptive routing of requests if connection tothe enterprise fails. The routers 130 will search thru the neighboringstores or nodes to act as a hub to send the request to the enterprise onits behalf. Every node or store may act as the hub to send a request toanother hub or store.

A snooper 132 periodically pings neighboring stores or nodes to updateits local cached directory 134 of the status of its neighboringstores/nodes. The policies detect what or where stores or nodes are“snooped” depending on where the current store or node is and when thesnooping takes place.

A route message (RouteMsg) module 136 handles requests coming from otherstores/nodes. The requests are either to route a message or inquiryregarding “message bean” route on behalf of another store. FIG. 2illustratively shows a data structure of an example message request.FIGS. 3 and 4 illustrate the logic to handle such a request. Anautonomic element 137 is also provided for monitoring and handlingfailure events, and notifying the sync-orchestrator 104 and the statemachine engine 114, which reacts to these events.

A policy may be defined as an expression that informs a decision makerof the criteria that it is to use in order to make decisions.

A brief description of the policy definition/grammar will be presentedhere for illustrative purposes. Policy making and implementation may bemade by other methods as well. A definition of a policy may be definedin terms of, e.g., 4-tuples. The 4-tuples components include Scope,Pre-Conditions, Measurement Intent and Business Value. This 4-tuple canbe expressed or stored in a standard XML format. The XML format policiescan also be easily loaded and translated into the 4-tuple format. Eachpolicy has a name which is called a decision name. A GUI-based policydefinition tool may be provided that allows users to create, modify anddelete policy definitions.

Scope includes a context or domain within which the policy applies, e.g.who is the subject of the intent of the policy. Pre-condition may bethought of as “if clauses” within a policy. The policy pre-conditionshould be evaluated as true to be considered as a candidate forexpression. Measurable intent may be thought of as “then clauses” withina policy. If the pre-condition is evaluated to true then this measurableintent will be returned. A measurable intent can be stated as asolicited Decision request, as an unsolicited Action or as anunsolicited Goal.

A Decision is a solicited request from application (Data Sync 102) for“Policy Guidance”. In response, the system will return one or morepieces of information. Both Actions and Goals represent unsoliciteddirection. An Action pushes pieces of information (rather like aDecision) down to the application. A Goal pushes an “objective” down toan application. Business value is a statement of business priority. Thisportion of a policy definition is used when there are conflicts betweenrelated policies and it is necessary to calculate economic tradeoffs.Business value may be substituted with any quantifiable comparison andneed not be economic in value or nature. For now, business value may beused for illustration purposes, but this policy definition may includeany simple numeric priority.

Using policy based methodology, “what” to sync, “when” to sync, “where”to sync and “how” to sync are all expressed in term of policies 112.Using this approach, an application system 140 having a plurality ofapplications 142 can separate data 144 from the logic, making theapplication system more “alive” and dynamic to handle differentsituations without changing the application codes.

By basing decisions, such as which synch engine should be selected, onpolicy, the system 100 does not need to change any setting, reboot thesystem or reset parameters. Instead, the policy dictates which synchengine is selected in accordance with say, a data type. Should thepolicy change, the policy is updated and the system continues to operatewithout resetting.

An example of using policy to express a sync request includes, e.g., ifa sync request policy is to perform the sync midnight everyday at onepoint, then later it is decided to change the sync schedule to 6 AM, theonly thing that needs to be performed is to update the policy withoutchanging the application codes and without shutting down and restartingthe application again. There are many ways of expressing policy andinterpreting policy.

Control flow from application system 140 provides a sync-request 190which captures the specific details of the synchronization demanded bythe component (e.g., application 142 or data 144). In an example where aplurality of retail stores communicate with an enterprise server, therequest 190 includes data object types (or “what”) that need to besynchronized between the in-store server and the enterprise server, thetime at which the synchronization needs to be performed (“when”) betweenthe in-store server and enterprise server, and the mechanism (“how”)that implements the synchronization.

The confirmation events and the notification rules for the component arealso provided in the request as well as a specification of theaudit-trails and log information needed for synchronization. The requestmay provide for handling of failures that could potentially occur duringthe synchronization process. The failure handling can be automated toprovide self-management capabilities.

The sync-request process and the data synchronization interaction withother components are depicted in FIG. 1. Once the request 190 isreceived the policy manager 110 is activated to handle the “what”,“when” and “how’ process for synchronization. The sync-orchestrator 104,based on the request data type, will invoke the appropriate data-syncengine 120, 122, 124, etc. based upon the policies 112 of the policymanager 110.

Web synch requests 191 are handled in the same way as requests 190. Inaddition, messages and queries (e.g., view status 192) may be satisfiedusing requests 191. Reponses 193 may be returned synchronized.

Calls for data sync requests may be asynchronous calls. The caller whorequested services will provide a callback object; the data synccomponent 102 will notify the caller through the callback when sync hasbeen completed (response 193). For on-schedule sync which is loaded atstartup time, a caller can register with data sync 102 to be notifiedwith the status (view status 192) of the sync.

The four major tasks in data synchronization include the tasks toschedule sync, handle due scheduled sync, on-demand sync and perform thesync. These are dynamic processes. During the instantiation of the datasynchronization singleton, all the scheduled sync requests defined inthe policies are loaded from the policy management system 112 and passthem to the scheduler 107 to handle the scheduling (schedule synch). Theon-demand sync requests are requested during runtime. It is preferablyan asynchronous request where the component provides a call-backfunction. The on-demand request is also handled by the scheduler 107 toput the request in the queue to maintain the order of similar requeststo maintain data integrity; and also oblige any relevant policies, ifany, imposed on the sync requests. For due scheduled sync, the timer 106notifies scheduler 107 when it is time to sync the scheduled sync, thescheduler 107 will put the due sync request in the queue to maintain theorder of similar requests in order to maintain data integrity; and alsooblige any relevant policies, if any, imposed on the sync requests.

For a sync request, it is through the scheduler 107 queue that the syncrequest is extracted from and sent to the data sync engine 120 to getsynced. A separate thread is created to handle the sync queue, thisthread will keep checking the queue for a sync request and as soon asthere's a request in the queue, it sends the request to the orchestrator104, the orchestrator 104 in turn would send the request to the datasync engine 120. When the sync status is returned from the data syncengine 120 through interface 128, all listeners registered to benotified for this specific sync request will be notified.

Referring to FIG. 2, a routing protocol is illustratively shown for arequest for synchronization in accordance with one embodiment of thepresent invention. A password 202 is used to identify the sender. Amessage number 204 provides a unique id to identify the message. Anorigin 206 may include an ip address and port (ip+port) to id theorigin, e.g., store/nodes, of the message. A destination 208 (ip+port)provides the final destination of the message. A command 210 (route,info, enquiry) provides a request to route or message route enquiry. Thepossible commands include route message, resend message, cancel messageto be routed, find address where the message was last sent, etc.Messages 212 provide the message(s) to be routed.

Referring to FIG. 3, a routing flow chart is provided showing anillustrative method for routing messages using system 100 (FIG. 1). AnInternet protocol (ip) or other communication line is checked forsuitability to determine if the connection is satisfactory. If not, thesnooper (132, FIG. 1) checks a next ip in block 226. If the connectionis satisfactory, the message is sent in block 222. An acknowledge checkis performed in block 224. If acknowledgement of receipt of the messageis made, then the last message destination is recorded in a repositoryblock 230, otherwise the path again goes to block 226.

When the message is stored in the repository, it is deleted in block 232and a message sent status is returned in block 234. After block 226, acheck for more ip's is performed in block 228. If more ip's are present,the messages are sent in block 222. Otherwise, the messages are storedin the repository in block 236 and a message not sent status is returnedin block 238.

Referring to FIG. 4, the routing module 130 of system 100 determineswhen to route message/requests within the system 100. In block 240, adecision is made to route a message or messages. In block 244, a checkon the connection to the destination is made, if ok, a check is madewhether the message can be routed on time in block 246. If it can berouted on time, the message is queued for sending in block 248, sent andacknowledged in block 250. If the message cannot be sent on time, anegative acknowledgement is provided in block 252.

If no routing is decided in block 240, a password check is performed inblock 242. If the password is valid in block 242, a check is performedto see if the message is in the repository in block 254. If not in therepository, a null message is returned in block 264. If the message isin the repository, a decision to resend the message is made in block256. If yes, the message is routed in block 258. If no, a decision tocancel the message is made in block 268. If the message is not to becancelled a last destination info check is made in block 262. If lastdestination information is available, it is returned in block 266,otherwise the process is ended. If the decision to cancel is made inblock 268, the message is deleted from the repository in block 260.

Every sync request has its own life cycle, for example a sync requestcould be in queue state while it is waiting for its turn to besynchronized or in a failed state when the sync process has failed. Async request that expects to be self managed and self recovered cannotrely on a static life cycle, the life cycle should be able todynamically change to respond to various aspects of behavior of thesystem and synchronization process. Finite state machines are employedwith system 100 and used to define all the possible dynamic changes ofthe states and the corresponding actions to the various states.

Using finite state machine mechanisms (114) also provides a simpleframework for customization where the sync request life cycle and thecorresponding actions can be changed or redefine easily without majorchange of the application codes.

Different state machines may be employed; two are illustrativelydepicted in FIGS. 4 and 5. One state machine 271 (FIG. 5) is used for anon-schedule sync request and another state machine 273 (FIG. 6) is foran on-demand sync request. These state machine definitions may bedefined in XML format which would be imported into the datasynchronization system at start up time. Whenever there is a need tochange the state machine definition in terms of states, action orevents; the only thing that needs to be changed is to update thedefinition (XML file) and reload it back to the system.

Referring to FIG. 7, a state machine engine 114 is employed for findingand creating state machines in accordance with requests fromorchestrator 104. A command to create a state machine 276 is providedfrom orchestrator 104, and an instance of a state machine is created andplaced in a state machine queue 278. An event processor 274 processesthe next state machine in queue 278 in accordance with events in anevent queue 270. The event is processed and an action is executed inexecute action block 272 in accordance with an action id. The results ofexecution are provided to components (e.g., orchestrator 104, scheduler107, optimizer 126, timer service 106, etc.).

Given the functionality, the state machine usage and policy-based systemas described above, embodiments of the present invention may beimplemented in a plurality of different applications. These functionsmay support at least one or more of the following capabilities. Thecapability: 1) to synchronize data from components, such as, commercecomponents e.g., catalogs, pricing, offers, orders, promotion, accesscontrol, membership profile information, etc.; 2) to synchronize databased on the requests from the applications, e.g., “on-demand”,“on-schedule” and “multi-channel”; 3) to orchestrate and to handlesynchronization processes between components on servers and the remoteenterprise server; 4) to handle synchronization based on policiesdefined by the managing entity of the retail store or node; 5) for thesynchronization engine to handle “what”, “when” and “how” forsynchronizing. The synch engine(s) can be pluggable into the overallframework to handle database to database sync or file-system basedsynchronization; 6) to handle failures of all kinds, e.g.,disconnection, memory, low disk-space, special exceptions and others; 7)to provide simple self-managing functionality to handle failures, andrecover from failures based on predefined and negotiated policies.

Referring to FIG. 8 with continued reference to FIG. 1, one embodimentof the present invention will now be described in terms of a retailstore chain having an enterprise or main computer or server 330 locatedremotely from a plurality of nodes (302, 312, 322), which may include,e.g., retail stores, fulfillment centers, warehouses, and the like. Anin-store server synchronization component or controller 102 as depictedin FIG. 1 is employed at each location and addresses the following usecases. Each location may include fewer than all of the capabilitiesoutlined by system 100 in FIG. 1.

The synchronization component 102 may include one of the followingsubcomponents: a synchronization engine (sync-engine) 120, 122, 124 forhandling the actual data synchronization between objects. Orchestrator(sync-orchestrator) 104 to manage the various synchronization processes.The autonomic element 137 for monitoring and handling failure events,and notifying the sync-orchestrator 104. The policy manager 110 tomaintain and invoke policies on synchronization requests placed bycomponents 304, 306, 308. The scheduler 107 to schedule periodicsynchronization requests for components that have subscribed to the syncengine 120, 122, and/or 124. The router 130 is employed to performadaptive routing of requests. An event manager (e.g., state machineengine 114) to handle event sensing and notification to appropriatecomponents through the sync orchestrator 104.

The synchronization controller 102 provides flexibility to allow forplug-and-play of sync-engines (e.g., relational and others), and supportstandards, support multiple data types such as files, file-system andrelational data. Advantageously, this is performed by employing policiesset by system 330.

In accordance with one aspect of the present invention, a flexiblepolicy-based model for handling component and data synchronization isprovided by synch component or synch controller 102 through the use ofpolicy management as implemented by orchestrator 104. These policiesprovide a flexible way to represent and specify what, when and how tosynchronize data. Autonomic functions 137 and state engines 114 forhandling failures such as disconnection, low disk-space, disk and memoryerrors, and others, and automatic recovery mechanisms to handlecomponent specific requirements on failure-recovery procedures are alsoprovided by controller 102.

Further, services to support modification of synchronization requestsand policies on synchronization during run-time, and management servicesfor components on composing, modifying, deleting, and obtaining statuson synchronization requests are also provided by controller 102.

An on-demand use-case provides functionality to any commerce component304, 306, 308 to request the synchronization of some or all parts of thedata that is managed by the component. The synchronization is donebetween the sync controllers 102 of the nodes 302, 312, 322, etc. andthe enterprise system 330, or between components with a node.

Consider a commerce component 304 (e.g., a catalog, price list,inventory amount, availability date, location, sale price, etc.), inthis case say, a catalog, that wishes to synchronize the catalog productinformation and price lists (corresponding to each of the products).

The use-case is as follows. The commerce component 304 composes arequest (sync-request) 305 for synchronization to be done for a specificdata set (e.g. product set or category tree) or a view of the data set.The commerce component 304 subscribes 307 to the synchronizationcomponent 102 for the sync operation to be done. The sync-orchestrator104 handles the specific sync-request and launches the sync process. Thesync-orchestrator 104 invokes the sync-engine with the appropriateparameters specified in the sync-request. The sync-orchestrator 104interprets the sync-requests parameters. Once the synchronization iscompleted, a sync-engine (e.g., 120, 122, 124, etc.) reports back thestatus to the sync-orchestrator 104, which then informs the specificcomponents through message passing or event mechanisms, as describedabove. If during synchronization, a failure occurs, the autonomicelement 137 registers the failure event (through, e.g., JMX) and informsthe sync-orchestrator 104 of the failure.

Based on the specific failure event, the sync-orchestrator 104 recoversfrom the failure based on the state of the sync-process.

An on-schedule use-case provides functionality to any commerce component(e.g., 304, 306, 308) to request the synchronization of some or allparts of the catalog at a given specific time or periodically. Theuse-case is as follows. A commerce component, say 306 requests asynchronization to be done for a specific data set (e.g. product set orcategory tree) at a specific time of day or periodically. The commercecomponent 306 subscribes 311 to the synchronization component for thesynch operation to be done. The sync-orchestrator 104 handles thespecific synchronization request 309 by launching the sync process. Theorchestrator 104 invokes the sync engine (e.g., 120, 122, and/or 124)with the appropriate parameters. If during synchronization, a failureoccurs, the autonomic element 137 registers the failure event (e.g.,through JMX) and informs the orchestrator 104 of the failure. Based onthe specific failure event, the orchestrator 104 recovers from thefailure based on the state of the sync-process using state machines 114.

An on-demand use-case provides functionality to any commerce componentto request the synchronization of some or all parts of the catalog. Theuse-case may be as follows. A user places an order through anotherchannel (e.g., phone or home web-browser). The user decides to pick upthe purchased goods from a nearby, recommended store (e.g., node 302)that has the good available. The user enters the store physically, andrequests to display the order just placed. The order component 304requests a synchronization to be done for a specific data set (e.g.product set or category tree). The order component 304 subscribes to thesynchronization component 100 for the synch operation to be done. Thesync-orchestrator 104 handles the specific synchronization request bylaunching the sync process. This may include opening a browser 317 andactivating a collaborative sharing button 319. Other triggering eventsand/or implementations may also be employed.

The orchestrator 104 invokes the sync engine (120, 122, 124, etc.) withthe appropriate parameters. If during synchronization, a failure occurs,the autonomic element registers the failure event (e.g., through JMX)and informs the orchestrator 104 of the failure, and the state machinereacts to the event.

A message adaptive routing use case handles failed connections to theenterprise system 330. Neighboring stores or nodes 302, 312, 322collaboratively share network and bandwidth resources. In one example,store 302 needs to send a message to enterprise 330 (or any store ornode). No connection from store 302 to enterprise 330 is available atthat time. Store 302 searches neighboring stores 312, 322 for storesthat willing and able to send the message to the enterprise 330 withinthe next number of minutes (specified or default, say, x minutes). Store312 responds positively and accepts the message. In the next fewminutes, say y minutes, the store 312 connection to the enterprise 330fails. Store 312 searches neighboring stores (302, 322) for stores thatare willing and able to send the message within the next x-y minutes.

Store 322 responds positively and accepts the message. Store 322 thensuccessfully sends the message to the enterprise 330. The next x+yminutes, store 302 queries store 312 for the status of the message.Store 312 responds with the store 322 ip address. Store 302 queriesstore 322 for the status of the message. Store 322 responds with theenterprise 330 ip address.

Other collaborative implementations may also be employed. For example,alternate nodes 312 and 322 may be employed as a way of communicatingwith system 330 if node 302 is unable to connect to node 330. Nodes 312and 322 may be employed to place an order, track a product or performother synch or collaborative functions.

Nodes 302, 312, 322 and 330 may include communication media 340, whichmay include a dedicated network or communication system, the Internet, atelephone system (wired or wireless), satellite or any other means forremote communication.

Referring to FIGS. 9 and 10, static diagrams show the interactionbetween illustrative core classes to perform some exemplary data synctasks. FIG. 9 shows component requests and shows the classes forinteraction when the data sync gets a request from a component. Therequest can be a non-demand sync, checking sync status or cancel a sync.FIG. 10 shows the class interaction when a sync begins and ends.Components depicted in FIG. 10 are also show in FIG. 1. Some of theobjects shown includes a listener object 382 which listens for acallback and responds with a synch notification 384. Also, asynchrecovery object 386 alerts policy manager 110 when a failure occursduring the synch process.

Referring to FIG. 11, a method for sharing information is illustrativelyshown. In block 410, an attempt to receive up-to-date information fromthe main computer (e.g., enterprise) is made, but fails from the localnode in the system. In block 415, a request for the up-to-dateinformation is then made to one or more alternate nodes which haveaccess the main computer or have accessed the main computer morerecently than from the node. In block 425, a reply and the up-to-dateinformation may be received from one of the alternate nodes wherein theup-to-date information is more current than a version stored on thelocal node, and preferably the information is equivalent to theup-to-date information stored on the main computer.

The requesting of the up-to-date information may include sending arequest for quote to the one or more alternate nodes to satisfy aconsumer need at the local node in block 416, requesting to employ analternate node as a hub for communication with the main computer inblock 417, tracking a product in the system in block 416, requesting analternate node to make a sale that the local node is unable to make inblock 419, and/or requesting availability of a product to the alternatenodes in block 420.

Advantageously, since controller 102 is policy based, synchronizationmay be performed on any data-type form of the request. Since the policysets up a synch engine to be assigned the task of synchronization of thedata type, any and all known data types can be handled and synchronizedby controller 102.

Having described preferred embodiments of a system and method (which areintended to be illustrative and not limiting), it is noted thatmodifications and variations can be made by persons skilled in the artin light of the above teachings. It is therefore to be understood thatchanges may be made in the particular embodiments disclosed which arewithin the scope and spirit of the invention as outlined by the appendedclaims. Having thus described aspects of the invention, with the detailsand particularity required by the patent laws, what is claimed anddesired protected by Letters Patent is set forth in the appended claims.

1. A system, comprising a data synchronization controller which enablessynchronization of a plurality of different data types between a maincomputer and one or more remotely disposed computer elements, thecontroller comprising: an orchestrator which responds to requests fordata synchronization for a plurality of components in accordance withpredetermined policies maintained by a policy management system; asynchronization interface controlled by the orchestrator in accordancewith the policies to select a synchronization engine to service requestsfor synchronization from the orchestrator.
 2. The system as recited inclaim 1, wherein the synchronization controller includes a snooper whichintermittently communicates with the one or more computer elements orthe main computer to determine if updates are needed.
 3. The system asrecited in claim 1, further comprising a router which manages deliveryand receipt of requests from and to the main computer or one or moreremotely disposed computer elements.
 4. The system as recited in claim1, further comprising a state machine engine which creates and manages adynamic life cycle of each synchronization request received by theorchestrator to ensure proper handling of each request.
 5. The system asrecited in claim 4, wherein the life cycles includes one of an on-demandsynchronization request life cycle and an on-schedule synchronizationlife cycle.
 6. The system as recited in claim 1, further comprising apolicy manager which interfaces between the policy management system andother components of the system including the orchestrator to providepolicy-based decision-making.
 7. The system as recited in claim 1,wherein the data synchronization engine is selected from a plurality ofdata synchronization engines wherein an appropriate synchronizationengine is selected to service each of the synchronization requests forthe plurality of different data types.
 8. The system as recited in claim1, wherein the system is provided for a retail store at a first locationand the controller collaborates with one of the main computer and theone or more computer elements at a different location.
 9. The system asrecited in claim 1, wherein the synchronization requests include routinginformation, a pass code, and a message identifier.
 10. The system asrecited in claim 1, wherein the system includes a distributed computersystem connected by a network and the synchronization request is sent byactivating a button on a browser interface.
 11. The system as recited inclaim 1, further comprising a module capable of redirectingsynchronization requests between the system, the main computer and theone or more computer elements.
 12. The system as recited in claim 1,further comprising a scheduler which arranges requests and ensurestimely handling of requests.
 13. The system as recited in claim 1,wherein upon changes to policies requests can be satisfied by the maincomputer or one of the remote computer elements without resetting.